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Beschreibung 

Verfahren zur Herstellung einer Verbindung zwischen einem 
Dienstanforderer (Client) und einem Dienstanbieter (Server) 
in einem dezentralen Mobilf unknetz 

Die Erfindung betrifft ein Verfahren zur Herstellung einer 
Verbindung zwischen einem Dienstanforderer (Client) und einem 
Dienstanbieter (Server) in einem dezentralen Mobilf unknetz 
mit Dienst- /Dienstanbieter- Suchservice (Service Discovery) , 
bei dem der Dienstanforderer (Client) zur Lokalisierung eines 
noch unbekannten Dienst anbieters (Servers) , der einen ge- 
wunschten Dienst zur Verfugung stellt, eine Dienstanf orde- 
rungsnachricht (Service Discovery Request = SD-REQ) in Form 
einer Multicastnachricht an lokal benachbarte Stationen des 
dezentralen Mobilf unknetz sendet, die IP-Router sind, und 
diese Stationen wiederum die Multicastnachricht an deren 
Nachbarstationen und schlieSlich zum Dienstanbieter (Server) 
weiterleiten, der mit einer Antwortnachricht (Service Disco- 
very Reply = SD-REP) antwortet . 

In zukiinftigen offentlichen breitbandigen Funknetzen werden 
die Routingmechanismen (Wegsuchemechanismen) von Ad Hoc- 
.Netzwerken (dezentrale Netzwerke mit vorzugsweise mobilen 
Stationen) zum Einsatz kommen. Das Ad-hoc Routing Protokoll 
basiert auf der IP (Internet Protocol) Paketvermittlung und 
hat die Aufgabe, innerhalb des Funknetzes einen Weg von dem 
Ursprungs- zu dem Zielknoten eines Datenflusses zu finden. Im 
Fall, dass keine direkte Verbindung besteht, besteht die Auf- 
gabe darin, einen Sat z -von Routern auszuwahlen, der -die- Uber- 
tragung der IP-Pakete ermoglicht. Die Router leiten empfange- 
ne IP-Pakete an den jeweils nachsten Router oder der Zielsta- 
tion weiter. 

Es gibt verschiedene Routingprotokolle fur Ad-hoc Netze. Die 
Aufgabe der Wegesuche wird in unterschiedlicher Weise zum 
Beispiel mit AODV (Ad hoc On Demand Distance Vector Routing 
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Protocol) , DSR (Dynamic Source Routing Protocol for Mobile Ad 
Hoc Networks) , DSDV (Destination-Sequence Distance-Vector for 
mobile Computers) Protokollen gelost . Im folgenden wird bei- 
spielsweise das AODV-Protokoll betrachtet . 

Allen genannten Routingprotokollen ist gemeinsam, dass zum 
Start der Wegsuche die IP-Adresse der Empf angerstation als 
Eingangsparameter dient . Das Rout ingpro toko 11 sucht, basie- 
rend auf dieser Information, einen giinstigen Weg durch das 
Netz. Die Signal is ierung der Nachrichten des Routingproto- 
kolls tragt bei steigender Mobilitat der Stationen mit einem 
groSen Anteil zum sogenannt en Signal isierungsoverhead ( w Bal- 
last" der Telekommunikation) bei. Bei den reaktiven Rou- 
tingprotokollen, wie AODV, werden "Route Request (R-REQ) 11 - 
Nachrichten uber das gesamte Funknetzwerk geflutet, wenn eine 
Route noch nicht bekannt oder veraltet ist. 

Es gibt verschiedenste Anwendungsf alle, bei dem die Adresse 
einer Zielstation zunachst nicht bekannt ist, es fehlt also 
die Eingangsinf ormation fur das Routing. Das ist zum Beispiel 
der Fall, wenn der mobile Endkunde zu einer Station Kontakt 
aufnehmen mochte, die einen bestimmten Dienst zur Verfugung 
stellt, ohne dass ihm der Rechnername oder die IP-Adresse be- 
kannt ist. Beispiele hierfiir waren, die Abfrage von ortsbezo- 
genen Information, die Abfrage von lokale Wetter information 
oder Positionsabf rage eines Bankautomaten in- der Nahe . 

Die Suche nach einem Dienstanbieter (Service Discovery) kann 
zentral mit einem "Verzeichnis-Dienst " oder dezentral gesche- 
hen ; - Im dezentralen Fall sendet deir Dienstanf orderer (Client) 
alien Stationen in einer gewahlten Entfernung eine "Service 
Discovery Request (SD-REQ) 11 -Nachricht . Die Stationen, die den 
entsprechenden Dienst anbieten (Server), antworten darauf . 
Die Antwort heifit dann "Service Discovery Reply (SD-REP)"- 
Nachricht. Bei der SD-REQ-Nachricht handelt es sich um eine 
Multicastnachricht , die alle Stationen in einem geograf ischen 
Bereich erreichen. Jede Station des Ad Hoc-Net zwerks reicht 
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die Multicastnachricht an ihre Nachbarstationen weiter. Ser- 
ver-Stationen antworten mit einer detailliert Beschreibung 
des angef orderten Dienstes in der SD-REP-Nachricht . 

Vorteilhaf terweise nimmt nun die Antwort eines Servers den 
Weg, den die "Service Discovery" -Nachricht kurz zuvor zuruck- 
gelegt hat. Wahrend bei dem Routingprotokoll AODV, prinzi- 
piell ein entsprechendes Verhalten vorhanden ist, ist dies 
bei SD-REQ- und SD-REP-Nachrichten jedoch nicht vorgesehen. 
Da Routingtabellen in den Routern nur bei der Verwendung des 
AODV-Protokolls angepasst werden, nicht aber beim Weiterlei- 
ten von Nachrichten des Service Discovery- Protokolls, muss 
gegenwartig nach dem Service Discovery auch noch eine Route 
zwischen den entsprechenden Stationen gefunden werden. 

Die folgende Sequenz musste bei der derzeitigen Definition 
des Ad hoc-Routingprotokolls befolgt werden: 

- Der Client flutet eine SD-REQ -Nachricht . 

- Bei jedem Server, der den Dienst anbietet, wird die Wegesu- 
che nach dem Dienstanf orderer gestartet . Das heiSt jeder Ser- 
ver flutet R-REQ- Nachricht en, urn eine Route zum Client zu er- 
zeugen. 

- Der Client antwortet jeweils mit R-REP. 

- Der Pfad zwischen Server und Client exist iert nun und der 
Server kann mit SD-REP antworten. 

- Der Client kann nun gegebenenf alls einen Server aussuchen 
und eine Verbindung zu diesem Server herstellen, urn den ge- 
suchten Dienst in Anspruch zu nehmen oder weitere Informatio 
nen zu erhalten. 

Eine weitere Losung fur die Vermeidung von Multicastnachrich 
ten beim Service Discovery ist, dass Server ihre Dienste bei 
einem zentralen Server registrieren. Clients wurden dann zu- 
nachst diesen zentralen Server kontaktieren, urn die IP- 
Adressen der Server zu bestimmen, die einen gesuchten Dienst 
anbieten. Hat ein Client nun einen Server ausgesucht, kennt 
er auch dessen IP-Adresse, und kann dann das normal e R-REQ 
schicken, um einen Weg zu dem Server zu bestimmen. 



200315404 



Nachteil dieser zweiten Losung ist, dass eine oder auch meh- 
rere Server-Datenbanken eingerichtet werden mussen. Die Ad- 
ressen dieser Stationen mussen irgendwie bekannt gegeben wer- 
den. Zudem muss die Client -Station dennoch Multicastnachrich- 
ten fluten, urn die Route zu der Server-Datenbank und bei Be- 
darf die Route zu dem Server zu bestimmen. 

* 

Es ist daher Aufgabe der Erfindung, ein Verfahren zur Her- 
stellung der Verbindung zwischen einem Dienstanf orderer 
(Client) und einem Dienstanbieter (Server) in einem dezentra- 
len Mobilfunknetz mit Dienst-/Dienstanbieter-Suchservice 
(Service Discovery) zu finden, welches das Problem des Signa- 
lisierungsoverheads minimiert . 

Diese Aufgaben der Erfindung werden durch das Verfahren mit 
den Merkmalen des Patentanspruches 1 gelost . Vorteilhaf te 
Weiterbildungen der Erfindung sind Gegenstand untergeordneter 
Patentanspriiche . 

Die Erfinder haben erkannt, dass es moglich ist, den Signali- 
sierungsoverhead zu minimieren, wenn auch die vom Dienstan- 
f orderer (Client) gesendete Multicastnachricht , die beim Auf- 
suchen des Dienstanbieters (Server) verwendeten Routingtabel- 
len in den Routern, mit Weginf ormationen zum Dienstanf orderer 
(Client) versehen wird. 

Entsprechend diesem Erf indungsgedanken schlagen die Erfinder 
vor 7 das an sich bekannte Verfahren zur Her st el lung einer 
- Verbindung zwischen einem -Dienstanf orderer (Client) und einem 
Dienstanbieter (Server) in einem dezentralen Mobilfunknetz 
mit Dienst-/Dienstanbieter-Suchservice (Service Discovery) , 
bei dem der Dienstanf orderer (Client) zur Lokalisierung eines 
noch unbekannten Dienstanbieters (Servers) , der einen ge- 
wunschten Dienst zur Verfugung stellt, eine Dienstanf orde- 
rungsnachricht (Service Discovery Request = SD-REQ) in Form 
einer Multicastnachricht an lokal benachbarte Stationen des 
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dezentralen Mobilfunknetz sendet, die IP-Router sind, und 
diese Stationen wiederum die Multicast nachricht an deren 
Nachbarstationen und schlieSlich zum Dienstanbieter (Server) 
weiterleiten, der mit einer Antwortnachricht (Service Disco- 
very Reply = SD-REP) antwortet , dahingehend zu verbessern, 
dass zur Zuruckverf olgung des Weges zum Dienstanf orderer 
(Client) den Routingtabellen der Stationen die Weginf ormatio- 
nen der Dienstanf orderungsnachricht und dessen Antwortnach- 
richt beige fugt werden. 

Hierdurch ist es moglich, die bisher vom Dienstanbieter not- 
wendigen Wegsuchanf ragen (Route Request = R-REQ) zu vermei- 
den, wodurch der Signal is ierungsoverhead im Mobilfunknetz er- 
heblich reduziert wird. 

In einer besonderen Ausfuhrung des Verfahrens kann die 
Dienstanforderungsnachricht (Service Discovery Request = SD- 
REQ) des zumindest einen Dienstanf orderers (Client) urn Ele- 
ment e einer Suchnachricht (Route Request R-REQ) des zumindest 
Dienstanbieters (Servers) erweitert werden. 

Beim R-REQ des AODV-Protokolls waren dies alle Elemente auSer 
diejenigen, die die unbekannte Zieladdresse betreffen, das 
heiSt W D", W G" , "Destination IP Address" und "Destination Se- 
quence Number" . 

In einer besonderen Ausfuhrung wird aufierdem die Antwortnach- 
richt (Service Discovery Reply = SD-REP) des zumindest einen 
Dienstanbieters (Server) um alle Elemente einer Wegantwort- 
- nachricht (Route Reply = R-REP) des zumindest* einen Dienstan- 
f orderers (Client) erweitert. 

Im Fall des AODV-Protokolls kann auf Grund der zusatzlichen 
Informationselemente jede Station, die diese SD-REQ- und SD- 
REP -Nachricht en empfangt, ihre internen Routingtabellen aktu- 
alisieren, so dass eine zweite explizite Wegesuche entfallen 
kann. 
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Es ist vorteilhaft, wenn als Wegsucheprotokoll , vorzugsweise 
ein AODV- oder ein DSR-Protokoll verwendet wird, dass in der 
Dienstanforderungsnachricht (Service Discovery Request) und 
in der Antwortnachricht (SD-REP) integriert wird. 

Diese Wegsuchprotokolle gehoren zu den reaktiven Routingpro- 
tokollen, wodurch eine sich andernde oder veraltete Route 
einfach aktualisiert werden kann. 

Alternativ dazu ist es vorteilhaft, wenn das Routingproto- 
koll, vorzugsweise AODV oder DSR, dahingehend erweitert wird, 
dass es bei Empfang von den erweiterten SD-REQ- und SD-REP- 
Nachrichten die lokalen Routingtabellen entsprechend mit den 
Weginf ormationen aktualisiert. 

Im Folgenden wird die Erfindung anhand bevorzugter Ausfuh- 
rungsbeispiele mit Hilfe der Figuren 1 bis 6 beschrieben, wo- 
bei in den Figuren folgende Bezugszeichen verwendet werden: 
1: Dienstanforderer (Client) /Station des Dienstanf orderers 
(Client.); 2: weitere Stationen; 3: Dienstanbieter (Ser- 
ver) /Station des Dienstanbieters (Server); 4: Service Disco- 
very Request; 4a: Service Discovery Request mit integrierten 
Routinginf ormat ionsel ement en ; 5: Route Request; 6: Route 
Reply; 7: Service Discovery Reply; 7a: Service Discovery 
Reply mit integrierten Routinginf ormat ionselementen; 8: Ad 
Hoc -Netzwerk . 

Die Figuren zeigen im einzelnen: 

Figur 1: Ad Hoc-Netzwerk, in dem ein Client eine Dienstan- 
forderungsnachricht in Form einer Multicastnach- 
richt aussendet ; 

Figur 2: Ad Hoc-Netzwerk aus Figur 1, in dem zwei Server ei- 
ne Wegsuchnachricht nach dem Client ebenfalls in 
Form jeweils einer Multicastnachricht aussenden; 
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Figur 3: Ad Hoc-Netzwerk aus den Figuren 1 und 2, in dem der 

Client eine Ant wort auf die Wegsuchnachricht zu den 

Servern zuriicksendet ; 
Figur 4: Ad Hoc-Netzwerk aus den Figuren 1 bis 3, in dem die 

Server den gewiinschten Dienst dem Client anbieten; 
Figur 5: Ad Hoc-Netzwerk, in dem ein Client eine Dienstan- 

forderungsnachricht in Form einer besonderen Multi- 

castnachricht aussendet ; 
Figur 6: Ad Hoc-Netzwerk aus Figur 5, in dem zwei Server den 

gewiinschten Dienst dem Client anbieten. 

In den Figuren 1 bis 4 wird das bekannte Verfahren zur Her- 
stellung einer Verbindung zwischen einem Dienstanf orderer 
(Client) 1 und einem Dienstanbieter (Server) 3 in einem Ad 
Hoc-Netzwerk 8 gezeigt. Der Ubersichtlichkeit wegen, werden 
die verschiedenen Verf ahrensschritte separat in den Figuren 1 
bis 4 dargestellt. Das Ad Hoc-Netzwerk 8 besteht in der ge- 
zeigten Ausfiihrung aus einem Dienstanf orderer (Client) 1, der 
einen bestimmten Dienst aus dem Netzwerk 8 abrufen will. Au- 
Serdem sind in diesem Ad Hoc-Netzwerk 8 mehrere Stationen 2 
vorhanden, die auch mobil sein konnen und verschiedene Diens- 
te anbieten konnen. Alle Stationen des Ad Hoc-Netzwerks 8 
sind Router und konnen uber das verwendete Routingprotokoll 
Verbindungen zu anderen Stationen des Ad Hoc-Netzwerkes 8 
schaffen. Den beiden speziellen Stationen, die den gewiinsch- 
ten Dienst des Dienstanf orderers (Client) 1 anbieten, wurde 
das Bezugszeichen 3 vergeben. Diese sind dann mir Dienstan- 
bieter (Server) 3 bezeichnet. Die Figuren zeigen: 

"Die Figur 1 zeigt, wie "der Dienstanf orderer (Client) 1, der 
einen gewiinschten Dienst, zum Beispiel Wetterdaten in einem 
bestimmten Gebiet, zur Bemachtigung/Erlangen des Dienstes • 
vorgeht. Da dem Dienstanf orderer (Client) 1 die Serveradres- 
se/IP-Adresse desjenigen Dienstanbieter (Server) 3, der die 
Wetterdaten zur Verfiigung stellen kann, in der Regel nicht 
bekannt ist, wird der Dienstanf orderer (Client) 1 eine 
Dienstanf orderungsnachricht, oder auch mit Service Discovery 
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* 

Request 4 bezeichnet, in das Ad Hoc-Net zwerk 8 schicken. Die 
Service Discovery Request 4 (gepunktete Pfeile) wird vom 
Dienstanforderer (Client) 1 in der Regel als Multicast- oder 
Broadcastnachricht an geographisch benachbarte Stationen 2 
gesendet. Diese Multicast- oder Broadcastnachricht wird von 
den Stationen 2 an deren benachbarte Stationen 2 weiter ge- 
leitet, bis diese letztendlich auch den oder die richtigen 
Dienstanbieter (Server) 3 erreichen. Das Verteilen aller hier 
genannten Nachrichten und insbesondere das "Uberf luten" des 
Ad Hoc-Netzwerkes 8 mit diesen Nachrichten wird als Signali- 
sierungsoverhead bezeichnet. Den beiden Dienstanbietern (Ser- 
ver) 3 geht lediglich die Dienstanf orderungsnachricht bezie- 
hungsweise die Service Discovery Request 4 des Dienstanf orde- 
rers (Client) 1 ein. Der Weg oder der Pfad auf dem diese Ser- 
vice Discovery Request 4 vom Dienstanforderer (Client) 1 zum 
Dienstanbieter (Server) 3 gekommen ist, kann nicht unter Ser- 
vice Discovery (Dienst-/anbieter Suchservice) nachvollzogen 
we r den . 

Die Figur 2 zeigt nun wie die beiden Dienstanbieter (Server) 
3 den Dienstanforderer (Client) 1 lokalisieren. Die beiden 
Dienstanbieter (Server) 3 senden in Form einer Multicastnach- 
richt eine Wegsuchnachricht , oder mit Route Request 5 be- 
zeichnet, an deren lokal benachbarte Stationen 2. Die Route 
Request 5 wird ahnlich der Service Discovery Request 4 vom 
Dienstanforderer (Client) 1 aus Figur 1 von Station 2 zu Sta- 
tion 2 und schlieSlich zum Dienstanforderer (Client) 1 wei- 
tergeleitet. Jedoch im Unterschied zur Service Discovery Re- 
quest 4 wird bei der Route Request 5 der Weg oder Pfad des 
Absehders, also der bei deh Dienstanbieter" (Server) 3', keriht- 
lich gemacht. So konnen beim Empfang von Route Request Nach- 
richten 5 des AODV-Protokolls die Stationen 2 ihre Routingta- 
bellen anpassen. Diese "Wegkennzeichnung" wird durch die ge- 
punkteten Kreise der Stationen 2 angedeutet . Auch bei diesem 
Verf ahrensschritt, in dem der Dienstanbieter (Server) 3 den 
Weg zum Dienstanforderer (Client) 1 sucht, kommt es zu einem 
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Uberfluten des Netzwerkes, in der Annahme, dass eine Route zu 
Station 1 des Dienstanf orderer (Clients) noch unbekannt ist. 

In Figur 3 wird dargestellt, wie der Dienstanf orderer 
(Client) 1 die Wegsuchnachricht Route Request 5 der beiden 
Dienstanbieter (Server) 3 beantwortet. Der Dienstanf orderer 
(Client) 1 kann nun nachvoll Ziehen auf welchen Wegen/Pfaden 
die Route Request 5 der beiden Dienstanbieter (Server) 3 ihn 
erreicht hat. Der Dienstanf orderer (Client) 1 schickt eine 
Antwort "Route Reply 6" auf jede Wegsuchnachricht der beiden 
Dienstanbieter (Server) 3, zum Beispiel auf dem Weg/Pfad, den 
die jeweils zugehorige Wegsuchnachricht genommen hatte. Diese 
Antwort Route Reply 6 wird durch einen durchgezogenen Pfeil 
symbol isiert, urn das Bekanntsein des Weges /Pfades zu kenn- 
zeichnen. 

In Figur 4 wird dargestellt, wie die beiden Dienstanbieter 
(Server) 3 auf dem bestimmten Weg/Pfad ihre Dienstbeschrei- 
bung in Form einer Service Discovery Reply 7 dem Dienstanfor- 
derer (Client) 1 ubermitteln. Der Dienstanf orderer (Client) 1 
kann nun zum Beispiel wahlen, welchen Dienstanbieter (Server) 
3 er in Anspruch nimmt. 

An dem, anhand der Figuren 1 bis 4 erlauterten, Verfahren 
wird deutlich, wie aufwendig die Lokalisierung im Ad Hoc- 
Netzwerk 8 ist. So zei'gen speziell die Figuren 1 und 2 den 
Effekt des Signalisierungsoverhead. Die "Uberf lutung" des Ad 
Hoc -Netzwerkes 8 mit zu vielen Nachrichten soil aber gerade 
vermieden werden. Hierzu wird in den Figuren 5 und 6 ein neu- 
"es" Verfahren zuf~ Herstellung" "der "Verbinduhg zwischen eihem 
Dienstanforderer (Client) und einem Dienstanbieter (Server) 
beschrieben, welches den Signalisierungsoverhead zumindest 
reduziert . 

Die Figur 5 zeigt das selbe Ad Hoc-Netzwerk 8, wie in den Fi- 
guren 1 bis 4 . Analog zu Figur 1 sendet der Dienstanforderer 
(Client) 1, der einen noch unbekannten Dienstanbieter (Ser- 
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ver) 3, der einen gewunschten Dienst anbietet, aufsucht, eine 
Multicastnachricht an lokal benachbarte Stationen 2 . Im Un- 
terschied zu Figur 1 besteht diese Multicastnachricht aus ei- 
ner Dienstanf orderungsnachricht , auch Service Discovery Re- 
quest 4a genannt, in der Inf ormationselemente des Route Re- 
quests integriert sind. Durch die integrierte Routingnach- 
richt werden beim Weiterleiten dieser Multicastnachricht von 
Station 2 zu benachbarter Station 2, die Routingtabellen 
durch das erweiterte Routingprotokoll angepasst. Durch das 
Anpassen der Routingtabellen kann der Weg/Pfad zum Dienstan- 
forderer (Client) 1 zuriickverf olgt werden. Diese w Wegkenn- 
zeichnung/Pf adkennzeichnung" wird durch die gepunkteten Krei- 
se der Stationen 2 angedeutet . An dieser Stelle sei erwahnt, 
dass auch die Stationen 1 und 3, also der Dienstanf orderer 
(Client) und die beiden Dienstanbieter (Server) , gleichzeitig 
auch Router sind. Das soil heifien, auch diese erzeugen, sen- 
den und empfangen und verarbeiten Nachrichten des Routingpro- 
tokolls und verhalten sich entsprechend den Regeln des Rou- 
tingprotokoll s . Insbesondere haben sie auch Routingtabellen. 
Aus diesem Grund sind auch die Stationen 1 und 3 in den Figu- 
ren 5 und 6 durch Kreise, mit gepunkteter Iiinie, dargestellt. 

In der Figur 6 wird dargestellt, wie die beiden Dienstanbie- 
ter (Server) 3 auf dem nun bekannten Weg/Pfad ihre Dienstbe- 
schreibung in Form einer Service Discovery Reply 7a den 
Dienstanf orderer (Client) 1 ubermitteln. Im Unterschied zu 
Figur 4 besteht diese Nachricht aus einer Antwortnachricht , 
auch Service Discovery Reply 7a genannt, in die alle Inf orma- 
tionselemente des Route Replys integriert sind. Durch die in- 
"tiegrierte "Rout ingnachricht "werden beim Weiterleiten dieser 
Nachricht von Station 2 zu benachbarter Station 2, die Rou- 
tingtabellen durch das erweiterte Routingprotokoll angepasst 
Durch das Anpassen der Routingtabellen kann der Weg/Pfad zum 
Dienstanbieter (Server) 3 zuruckverf olgt werden. Diese u Weg- 
kennzeichnung/Pfadkennzeichnung" wird durch die gepunkteten 
Kreise der Stationen 2 dargestellt. Der Dienstanf orderer 
(Client) 1 kann nun zum Beispiel wahlen, welchen Dienstanbie 
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ter (Server) 3 er in Anspruch nimmt und zum Beispiel eine Da- 
tenverbindung, ohne weitere Wegsuche, zu einem von beiden 
auf baut . 

Der Vorteil an diesem neuen Verfahren ist, dass der Signali- 
sierungsoverhead, der beim Versenden von Wegsuchnachrichten 
vom Dienstanbieter (Server) 3 zum Dienstanf orderer (Client) 1 
in Form von Multicastnachrichten, wie sie in Figur 2 gezeigt 
werden, ent fallen kann. 

Insgesamt wird ein neues Verfahren zur Herstellung einer Ver- 
bindung zwischen einem Dienstanf orderer (Client) und einem 
Dienstanbieter (Server) in einem dezentralen Mobilfunknetz , 
vorzugsweise in einem Ad Hoc -Mobilfunknetz oder einem reakti- 
ve Ad Hoc-Netzwerk-Protokolle nutzendes Mobilfunknetz, mit 
Dienst-/Dienstanbieter-Suchservice (Service Discovery) zur 
Verfugung gestellt, welches weniger Multicastnachrichten be- 
notigt und somit das Problem des Signalisierungsoverheads mi- 
nimiert . 

Es versteht sich, dass die vorstehend genannten Merkmale der 
Erfindung nicht nur in der jeweils angegebenen Kombination, 
sondern auch in anderen Kombinationen oder in Alleinstellung 
verwendbar sind, ohne den Rahmen der Erfindung zu verlassen. 
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Patent anspriiche 
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Verfahren zur Herstellung einer Verbindung zwischen einem 
Dienstanf orderer (Client) (1) und einem Dienstanbieter 
(Server) (3) in einem dezentralen Mobilf unknetz (8) mit 
Dienst-/Dienstanbieter-Suchservice (Service Discovery) , 
bei dem der Dienstanf orderer (Client) zur Lokalisierung 
eines noch unbekannten Dienstanbieter s (Servers) (3) , der 
einen gewunschten Dienst zur Verfiigung stellt, eine 
Dienstanf orderungsnachricht (Service Discovery Request = 
SD-REQ) (4) in Form einer Multicastnachricht an lokal be- 
nachbarte Stationen (2) des dezentralen Mobilf unknetz (8) 
sendet, die IP-Router sind, und diese Stationen (2) wie~ 
denim die Multicastnachricht an deren Nachbarstationen 
(2) und schlieSlich zum Dienstanbieter (Server) (3) wei- 
terleiten, der mit einer Antwortnachricht (Service Disco- 
very Reply = SD-REP) (7) antwortet, 
dadurch gekennzeichnet , 

dass zur Zuruckverf olgung des Weges zum Dienstanf orderer 
(Client) (1) den Routingtabellen der Stationen (2) die 
Weginf ormationen der Dienstanf orderungsnachricht und des- 
sen Antwortnachricht beigefugt werden . 




30 



Verfahren gemaS dem voranstehenden Patent anspruch 1, 

■ 

dadurch gekennzeichnet, 

dass die Dienstanf orderungsnachricht (SD-REQ) (4) des zu 
mindest einen Dienstanf orderers (Client) (1) um Elemente 
einer Suchnachricht (Route Request = R-REQ) (5) des zu- 
mindest einen Dienstanbieters (Servers) (3) erweitert 
wixd; - — 
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3 . Verf ahren gemafi einem cier voranstehenden Patentanspruche 
1 und 2 , 

dadurch gekennzeichnet , 

dass die Antwortnachricht (SD-REP) (7) des zumindest ei- 
nen Dienstanbieters (Server) um alle Elemente einer Weg- 
antwortnachricht (Route Reply = R-REP) (6) des zumindest 
einen Dienstanf orderers (Client) (1) erweitert wird. 

4 . Verf ahren gemaS einem der voranstehenden Patentanspruche 
1 bis 3, 

dadurch gekennzeichnet, 

dass als Wegsucheprotokoll , vorzugsweise ein AODV- oder 
ein DSR-Protokoll verwendet wird, dass in der Dienstan- 
f orderungsnachricht (SD-REQ) (4) und in der Antwortnach- 
richt (SD-REP) (7) integriert wird. 

5 . Verf ahren gemaS einem der voranstehenden Patentanspruche 
1 bis 4, 

dadurch gekennzeichnet, 

dass das Rout ingpro toko 11 , vorzugsweise AODV oder DSR, 
dahingehend erweitert wird, dass es bei Empfang von den 
erweiterten SD-REQ-Nachrichten (4a) und SD-REP- 
Nachrichten (7a) die lokalen Routingtabellen entsprechend 
mit den Weginf ormat ionen aktualisiert . 
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Zus ammenf a s sung 

Verfahren zur Herstellung einer Verbindung zwischen einem 
Dienstanf orderer (Client) und einem Dienstanbieter (Server) 
in einem dezentralen Mobilfunknetz 

Die Erfindung betrif ft ein Verfahren zur Herstellung einer 
Verbindung zwischen einem Dienstanf orderer (Client) (1) und 
einem Dienstanbieter (Server) (3) in einem dezentralen Mobil- 
funknetz (8) mit Dienst-/Dienstanbieter-Suchservice (Service 
Discovery) , bei dem der Dienstanf orderer (Client) zur Lokali- 
sierung eines noch unbekannten Dienstanbieters (Servers) (3) , 
der einen gewunschten Dienst zur Verfugung stellt, eine 
Dienstanforderungsnachricht (Service Discovery Request = SD- 
REQ) (4) in Form einer Multicastnachricht an lokal benachbar- 
te Stationen (2) des dezentralen Mobilfunknetz (8) sendet, 
die IP-Router sind, und diese Stationen (2) wiederum die Mul- 
ticastnachricht an deren Nachbar stationen (2) und schlieSlich 
zum Dienstanbieter (Server) (3) weiterleiten, der mit einer 
Antwortnachricht (Service Discovery Reply = SD-REP) (7) ant- 
wortet . 

Das Verfahren zeichnet sich dadurch aus, dass zur Zuruckver- 
folgung des Weges zum Dienstanf orderer (Client) (1) den Rou- 
tingtabellen der Stationen (2) die Weginf ormationen der 
Dienstanforderungsnachricht und dessen Antwortnachricht bei- 
ge fiigt werden . 

Figur 5 



» * 



200315404 



1/3 



FIG1 

Stand derTechnik 




.CD 



0"" 



4 

..i — 







FIG 2 

Stand der Technik 



8 




XD 




\ 2 j 



200315404 

« 



2/3 

8 




FIG 4 

Stand der Technik 




2 



i 2 



... 

\ 2 } 



20031 5404 




3/3 



FIG 5 



8 



3^ 

\ — / 
« *• * 




I ? r A ... — ./ / V / / 



FIG 6 



8 





(2 

**••»«••* 



(2 ) 



I 2 ) 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record. 



BEST AVAILABLE IMAGES 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 



fB BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 



jPB REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 
□ OTHER: 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 





LINES OR MARKS ON ORIGINAL DOCUMENT 



